Pin every workflow action to an exact current release - #4

Both workflows were a major version behind on checkout, two majors behind on setup-uv, and carried floating tags elsewhere.

Every version read from the upstream releases/latest, not from memory.

The setup-uv jump needed its changelog, not just its version number

Crossing two majors, so I read both release notes before touching it. Two things came out of that:

v8 stopped publishing major and minor tags deliberately. Pinning to @v9 would reopen exactly the supply-chain hole they closed after the tj-actions compromise — an exact release is the only supported form now. So this is not merely a style preference here; it is the upstream's requirement.

v9's single breaking change flips prune-cache from true to false, which grows the Actions cache instead of trimming it and can raise cost. That default is set back explicitly, so this upgrade changes versions and nothing else.

Their other breaking change — the manifest-file format — does not apply, since neither workflow defines one.

Also

Both checkouts set persist-credentials: false. Neither workflow pushes, so nothing needs the token left in .git/config.

Verification

⚠️ workflow.yaml only runs on a published release, so no pull request exercises it — the green check on this PR says nothing about the publish path. It was verified separately:

• all three workflow files parsed locally
• the release build job reproduced end to end:
  • uv build produced both artifacts, including the macosx_14_0_arm64 native wheel
  • check_release_artifacts.py passed on both
  • the native backend smoke test reported {'native': True, 'metal_available': True, ...}
• the built wheel carries the new Homepage, Keywords, and description metadata

The Tests check on this PR does cover the risky half: it runs checkout@v7.0.1 and setup-uv@v9.0.0 on the same macos-15 runner and with the same inputs that workflow.yaml uses.